Thorsten Froehlich wrote:

>> Do you know how RTTI internally works? (I.e. in an "non-shitty"
>> compiler.)
> 
> It is very simple (of course there are other ways to do it).  In essence,
> all you need is a single static type_info object for every class.  So, you
> create one static instance of such an object (ideally you have the linker
> fold multiple instances). Every virtual function table gets a pointer to
> the type information. For PODs and structs you know the type at
> compile-time anyway. So, all you need it one pointer per class to
> determine its type, plus 50 or so bytes (depending on what the name string
> of type_info returns) per class (not per object!). And of course, the
> compiler will only need to generate this data if type information is
> required for a particular class.
> 
Okay, that explains all the strings one sees in the binary when turning 
on RTTI. It is probably responsible for most of the size overhead when 
using RTTI. 

But what do we need the type name string for? (..in a binary!) 
[Apart from an error message.]

What you did not mention is some sort of tree structure. I'm not 
sure about the details, but isn't there the need for a tree traversal 
to decide if the dynamic_cast is valid? (Think of multiple inheritance...)

Wolfgang

Post a reply to this message